Many electronic devices are single die integrated circuits, where a microcontroller, e.g. an Advanced RISC Machine (ARM) or 8051 (Intel MCS-51) core, controls multiple peripherals such as a serial link, general-purpose input/output (GPIO) or other device. The microcontroller data and code are stored in internal memories of the microcontroller, e.g. flash, Electrically Erasable Programmable Read-Only Memory (EEPROM), Read Only Memory (ROM) or other suitable memory.
Some of these devices are used in applications where security is important, for example in transactions such as money transfers or in power meters or credit cards. It is important to ensure that the execution flow of the program in such cases is not modified by an attacker.
Such microcontroller devices operate on an input using a stored program and stored data to produce an output. The program has executable instructions that are executed by the microcontroller in a dictated order, with the content of registers pushed and popped to a last-in-first-out structure, such as a stack, for efficient computation. A program counter (PC) is used to indicate the address or another value representative of the next instruction to be fetched or executed. The PC is a register of the microcontroller. For example, in a Cortex M0 core it is the R15 register. The PC is automatically incremented by the microcontroller hardware or pushed/popped from the memory stack by a specific instruction, such as a call subfunction, dependent upon the decode instruction. Typically, after each instruction is executed, the PC is updated by the microcontroller to point to the next instruction (for example, the address of the next instruction).
One way in which an attacker could compromise the system could be by trying to skip lines of code (such as a line checking whether the correct PIN code has been entered) by inserting a fault at the correct time. Faults may be introduced using multiple light pulses or power spikes. Alternatively, an attacker could take advantage of software bugs, so that, via a. buffer overflow, code is inserted or a return oriented programming (ROP) attack is executed. A non-exhaustive list of assets which can be manipulated to disrupt execution flow include a microprocessor, the PC value, a status bit, the register content (for example modifying a loop counter or an address), an instruction operand and an Arithmetic Logic Unit (ALU) computation. Additionally, the computation stack may be manipulated, for example by altering a variable stored in the stack or the return address in the stack. Finally, other areas may be attacked, such as the content of the processor register.
As these attacks can be generated in many ways, for example by voltage or clock glitches, low or high temperatures, laser pulses, or by logical means such as buffer overflows, and in many parts of the integrated circuit, it is difficult to protect against all of them.
To protect against execution flow manipulation, what is usually done is to perform, in parallel to normal processing, some additional computation. The result of this computation can then be checked and cross-referenced, the idea being that it would be difficult for an attacker to simultaneously modify two parallel processes. For instance, to ensure that critical loops are executed the correct number of times, an additional counter can be used to cheek the loop counter during and after the loop.
1.loopCount = 0;2.for (i=0; i<length; i++){3.do something;4.if (loopCount != i){ {throw error};5.loopCount++;6.}7.if (loopCount != (length−1)){throw error};
Drawbacks of protecting against disruption of the execution program flow in the software itself are that this impacts system performance because the executed code will grow in size as the same operations are performed multiple times, so it cannot be systematic. Additionally, development time in increased as the additional code must be inserted and tested.
Moreover, such code is vulnerable to the same attacks as the code it protects. The method therefore in effect relies on the hope that the attacker will not have enough ‘bullets’.
The present disclosure aims to alleviate these issues by providing a hardware unit that checks the execution flow in real time and flags if the execution flow has been compromised.